Formelberechnung
Mit Computern kann man rechnen. Das ist toll und gut so. Wenn man allerdings Berechnungen Außerhalb eines Programms definieren möchte, dann kommt man schnell an die Grenzen. Einfache Operationen sind schnell programmiert und ausgewertet, bei komplexen Operationen kommt man jedoch schnell ins Schwitzen. Gottseidank besitzt SAP einen Formeleditor, den man sehr einfach für eigene Berechnungen verwenden kann. Mit entsprechenden Funktionsbausteinen oder einer Klasse kann eine Formel geprüft und ausgewertet werden.
Funktionsbausteine
Es gibt zwei Funktionsbausteine: Einen für die Prüfung einer Formel und einer für die Berechnung:
Prüfung: CHECK_FORMULA
Berechnung: EVAL_FORMULA
Beide Funktionsbausteine haben die folgenden Parameter:
FORMULA: Enthält die Formel
PROGRAM: Programmname zur Wertzuweisung
ROUTINE: Name des Unterprogramms zur Wertzuweisung
Einfache Berechnung einer Formel
Der einfachste Aufruf zur Berechnung einer (fast) beliebigen Formel erfolgt mit dem Funktionsbaustein EVAL_FORMULA. Es reicht, wenn du diesem Baustein die Berechnung mitgibst, z.B. 10*3:
Berechnung mit Variablen
Nun möchte man natürlich nicht nur Werte berechnen, sondern auch mit Variablen arbeiten, wie zum Beispiel “A + B”. Das funktioniert mit den Funktionsbausteinen ebenfalls. Die Formel lautet: A+B. Allerdings müssen die Werte natürlich zugewiesen werden. Hierfür muss man den Programmnamen und den Namen des Unterprogramms angeben, in dem die Werte zugewiesen werden. Ein kleines Beispielprogramm lautet: RSCALC01. Die folgenden Berechnungen werden durchgeführt; die Wertezuweisung erfolgt im Programm.
FUESSE + AEDERCHEN + OEHRCHEN 6,0000000000000000E+00 (-B+SQRT(B**2-(4*A*C)))/(2*A) 4,0000000000000000E+00 0**0 1,0000000000000000E+00 -16**0.5 -4,0000000000000000E+00
Formelspeicher
Formeln können zentral in der Tabelle TFKT abgelegt werden. Du kannst also eine Formel VOLUMEN hinterlegen: BREITE * HOEHE * LAENGE.
In deinem Programm musst dann eine entsprechende Zuweisung zu diesen Variablen BREITE, HOEHE, LAENGE machen. Nun ändert sich so eine Volumenberechnung natürlich nicht. Es sei denn, man hinterlegt einen Sicherheitswert, um das Volumen etwas zu vergrößern, also z.B.: BREITE * HOEHE * LAENGE * 1,005
In diesem Fall kann die Volumenberechnung in mehreren Applikationen verwendet werden und sobald der Sicherheitswert geändert wird, wird dies in allen Berechnungen berücksichtigt.
Eine andere Variante wäre, dass jeder Dimension ein eigener Sicherheitswert zugewiesen wird:
KEY | Formeltext |
VOLUMEN | TFKT:BREITE * TFKT:HOEHE * TFKT:LAENGE |
BREITE | BREITE + 1 |
HOEHE | HOEHE + 1 |
LAENGE | LAENGE + 2 |
Die Tabelleneinträge lassen sich mit Transaktion SE16N bearbeiten; es gibt keinen Tabellenpflegedialog dafür… Sollte die Benutzung mit SE16n nicht möglich sein, so kann jedoch schnell ein Tabellenpflegedialog für die Tabelle generiert werden.
[notice type=’info’]Aus der Doku zum Funktionsbaustein CHECK_FORMULA
Wenn eine Benutzergruppe eine andere Tabelle als TFKT benötigt (um z.B. den Schlüsselteil zu strukturieren oder eigene Felder aufzunehmen), sollte die Referenztabelle TFKT zunächst kopiert werden. Eigene Funktionen können bei Bedarf ab Position 79 angefügt werden.
Eine Tabelle, die zur Formelablage verwendet wird, muß eine Schlüssellänge von 13 und einen Funktionsteil der Länge 65 besitzen.[/notice]
Parameter
Formeln können auch Parameter enthalten, so dass du zum Beispiel die Formel VOLUMEN mit entsprechenden Werten aufrufen kannst:
VOLUMEN(10,20,30)
Die Parameter werden durch Komma getrennt. Die formalen Parameter in der Formel beginnen mit # und werden durchnummeriert. Die Berechnung für das Volumen sieht dann so aus:
VOLUMEN: #1*#2*#3
[notice type=’info’]SAP-Hinweis: 560672 – Selbstdefinierte Formeln in Tabelle TFKT[/notice]
Demoprogramm
REPORT zz_demo_formula. *== selection screen
PARAMETERS p_formel TYPE char50 DEFAULT 'TFKT:VOLUMEN'. PARAMETERS p_breite TYPE p DECIMALS 2 DEFAULT 10. PARAMETERS p_hoehe TYPE p DECIMALS 2 DEFAULT 10. PARAMETERS p_laenge TYPE p DECIMALS 2 DEFAULT 10. PARAMETERS p_result TYPE p DECIMALS 2 MODIF ID x. *== DATA DATA gv_retcode TYPE i. DATA gv_repid TYPE repid VALUE sy-repid. *== set result field to Display only AT SELECTION-SCREEN OUTPUT. LOOP AT SCREEN. IF screen-group1 = 'X'. screen-input = '0'. MODIFY SCREEN. ENDIF. ENDLOOP. AT SELECTION-SCREEN. *== check formula (Syntax check) CALL FUNCTION 'CHECK_FORMULA' EXPORTING formula = p_formel program = gv_repid routine = 'CHECK_VALUES' IMPORTING subrc = gv_retcode. *== compute formula IF gv_retcode IS INITIAL. CALL FUNCTION 'EVAL_FORMULA' EXPORTING formula = p_formel program = gv_repid routine = 'GET_VALUES' IMPORTING value = p_result EXCEPTIONS OTHERS = 1. ENDIF. *&---------------------------------------------------------------------* *& Form GET_VALUES *&---------------------------------------------------------------------* FORM get_values USING parm CHANGING wert subrc. CASE parm. WHEN 'BREITE'. wert = p_breite. subrc = 0. WHEN 'HOEHE'. wert = p_hoehe. subrc = 0. WHEN 'LAENGE'. wert = p_laenge. subrc = 0. ENDCASE. ENDFORM. "GET_VALUES *&---------------------------------------------------------------------* *& Form CHECK_VALUES *&---------------------------------------------------------------------* FORM check_values USING parm CHANGING subrc. CASE parm. WHEN 'BREITE' OR 'HOEHE' OR 'LAENGE'. subrc = 0. ENDCASE. ENDFORM. "CHECK_VALUES
Bugs/ Probleme
Ich habe es nicht geschafft, den Parameter UNIT_OF_MEASURE sinnvoll einzusetzen. In obigem Beispiel mit der Volumenberechnung wäre es natürlich schön, wenn ich eine Berechnung in Metern durchführen möchte, jedoch immer genau 1 CM Sicherheitsabstand addiert werden soll. Es scheint jedoch so, als würde der Parameter komplett ignoriert werden. Eventuell habe ich aber die Verwendung nicht richtig verstanden…
[notice type=’alert’]912586 – Formelinterpreter: geschachtelte Aufrufe mit Parametern
1324714 – Formelinterpreter: Fehlerhafte Berechnungen bei TFKT [/notice]
Demoprogramm RSCALC10 funktioniert nicht.
- 7. December: Excel Racing Simulation – Root Vole Race - 7. Dezember 2024
- 5. December: ABAPConf - 5. Dezember 2024
- 4. December: Only a lazy developer is a good developer - 4. Dezember 2024